Method and apparatus for providing pre-existing and prospective customers with an immediately accessible account

ABSTRACT

A system and method for providing in real-time an immediately accessible customized transaction account via the internet is disclosed. In particular, the system and method recognizes distinct access codes which are correlated to the credit profile of a person accessing an on-line application system via a computer network. During operation of the invention, a party may be driven to the on-line application system via the internet to conduct a transaction in response to an invitation to enroll in a special program. Upon entering the on-line application system, the accessing party may be unilaterally given the opportunity to apply for a special offer, which has been tailored to the accessing party&#39;s credit profile.

RELATED APPLICATIONS

This patent application claims priority to, and the benefit of, U.S.patent application Ser. No. 12/831,067, entitled “METHOD AND APPARATUSFOR PROVIDING PRE-EXISTING AND PROSPECTIVE CUSTOMERS WITH AN IMMEDIATELYACCESSIBLE ACCOUNT” filed on Jul. 6, 2010. The '067 application claimspriority to, and the benefit of, U.S. Pat. No. 7,778,920 issued on Aug.17, 2010 (aka U.S. patent application Ser. No. 10/082,171, entitle“METHOD AND APPARATUS FOR PROVIDING PRE-EXISTING AND PROSPECTIVECUSTOMERS WITH AN IMMEDIATELY ACCESSIBLE ACCOUNT” filed on Feb. 25,2002). The '920 patent claims priority to, and the benefit of, the U.S.provisional patent application U.S. Ser. No. 60/277,539, entitled“SYSTEM AND METHOD FOR RECOGNIZING PRE-EXISTING CUSTOMERS” filed on Mar.20, 2001, and U.S. provisional patent application U.S. Ser. No.60/311,541, entitled “SYSTEM AND METHOD FOR PRE-APPROVED INTERNETAPPLICATIONS” filed on Aug. 10, 2001. All of which are herebyincorporated by reference.

FIELD OF INVENTION

The present invention generally relates to identifying anddistinguishing between pre-existing card holders and prospective cardholders accessing an on-line system maintained by a card provider, andproviding the accessing party with personalized enrollment offers.

BACKGROUND OF THE INVENTION

In recent years, the convenience of using transaction cards in financialtransactions has led to an increased number of transaction card holdersworldwide. To increase revenues from the increased card usage,transaction card providers are typically seeking new methods to increasethe number of users of their card provider systems. One method which isemployed involves providing prospective users with “pre-approval.”Pre-approved offers are typically designed to encourage the prospectiveuser to become a customer (e.g., card holder, transaction accountenrollee, etc.) of the transaction card provider. In a conventionalpre-approval offer a prospective card holder is informed that theprospective card holder fits a pre-determined criteria, which allows theprospective card holder to apply for, and subsequently receive, a card,financial account or transactional account system by the card provider.In addition, the prospective card holder's pre-approval status providesthe prospective card holder access to certain special offers related tothe financial systems.

Traditional methods of informing prospective card holders of theirpre-approval status involves using direct mailers or telephoniccommunications. Where direct mailers or telephonic communications areused, the pre-approved customer is often invited to complete anapplication for enrollment in the systems for which the person ispre-approved. For example, where the invitation is communicated to theprospective card holder via direct mail, the prospective card holdermust typically complete an application form provided in the directmailer and return the application to the card provider for processing.Alternatively, the direct mailer may invite the prospective card holderto telephone the card holder and complete the applicationtelephonically. Further still, where the pre-approval offer iscommunicated to the prospective card holder via a phone call initiatedby the card provider, the card provider informs the prospective cardholder of the pre-approval status. During the telephone communication,the prospective card holder is then invited to complete an applicationfor enrollment in the provider's systems.

Another method which may be used by prospective card holders to applyfor enrollment in a pre-approved program takes advantage of the growingpopularity of the Internet. With the increased usage of the internet toconduct e-commerce, transaction card providers are often developingon-line application systems (e.g., web site based application sitemaintained on a card provider server). An on-line application system isa method provided by a financial institution, such as, a transactioncard provider, which allows a prospective customer to apply forfinancial systems, transact commerce, or other such activities via acomputer network. To increase usage of the on-line application system, acard provider may communicate the on-line application option via adirect mailer or telephonically as is currently done with thetraditional application methods discussed above. In this way, theprospective customer is driven to the on-line application system tocomplete the pre-approved application.

One problem associated with the above methods is that the invitation toapply is often not made personal to the prospective customer (e.g.prospective card holder). That is, the invitation may involve a generalpre-approval offer not tailored to a specific background (e.g., creditprofile, purchase history, demographic data, etc.) of the prospectivecustomer. In particular, the offer may be identical to an offer which ismailed to a multitude of prospective card holders, without taking intoconsideration any one individual prospective card holder's currentfinancial, purchase or demographic profile (collectively called“customer profile” herein).

Another method which is used by financial institutions to increase thenumber of card users involves encouraging pre-existing transaction cardholders (e.g. pre-existing transaction account enrollees) to enroll inother transaction cards or financial or transactional systems offered bythe card provider. Similar to the prospective card holders, thepre-existing card holders are often contacted using the direct mailer ortelephonic methods described above. That is, the pre-existingtransaction card holder is typically either forwarded a direct mailer orreceives a telephonic communication informing the pre-existing cardholder that the pre-existing card holder has been pre-approved forenrollment in other systems offered by the card provider. Thepre-existing card holder is then invited to apply for the other systemsby filling out a pre-approval application and forwarding the applicationto the card provider for processing. Alternatively, where thepre-existing card holder is contacted by telephone, the pre-existingcard holder is invited to telephonically enroll in the other systems.

In addition to the above, the pre-existing card holder may be driven toan on-line application system maintained by the financial institution.That is, the pre-existing card holder may be invited, via direct maileror telephonically, to access a card provider on-line application via acomputer network where the pre-existing card holder may complete apre-approval application. As with the prospective card holder, however,conventional on-line application systems are limited in their ability torecognize the pre-existing card holder and subsequently offer thepre-existing card holder a special offer tailored to the pre-existingcard holder's customer profile.

As such, a system is needed that recognizes and distinguishes betweenpre-approved prospective card holders and pre-approved pre-existing cardholders for the purpose of extending offers specially tailored to theindividual prospective card holder and pre-existing card holder'scustomer profile. Such a system would reduce or eliminate the costassociated with traditional direct mailer or telephonic communicationmethods, thereby increasing the card provider's revenues. A desiredsystem would allow a more convenient method for enrolling new users in acard provider's (e.g. transaction account provider's) system, or toupgrade an existing system.

SUMMARY OF THE INVENTION

The present invention addresses many of the shortcomings of the priorart, particularly in the ability of an on-line application system tofacilitate recognition of an accessing party and to offer individualized(e.g., customized) enrollment offers. It should be noted that althoughthe present invention is described with respect to a transaction card,such as a transaction card, debit card, smart card, stored value card,or similar financial/banking card, the invention is not to be solimited. For example, the present invention is applicable to any suchfinancial or transactional account arrangement wherein the financialsystem transactional account provider offers pre-existing enrollees andprospective enrollees individualized, customized, or personalizedenrollment offers. Such a financial or transactional arrangement mayrequire the provider to maintain a database, or collection of databases,wherein information regarding a prospective enrollee's customer profileis stored.

In accordance with one aspect of the present invention, a prospectivecard holder (e.g.

prospective transactional account enrollee) or pre-existing card holder(e.g. pre-existing transactional account enrollee) may access an on-lineapplication system maintained by a card provider (e.g. transactionaccount provider) server. The prospective card holder may then provide apre-approval code to the card provider server. A transaction cardprovider server facilitates verification of the validity of thepre-approval code prior to allowing the prospective card holder toenroll in a pre-approved individually tailored (e.g., customized) systemor program offered by the provider.

In the instance where the party accessing the on-line application systemis a pre-existing card holder, the pre-existing card holder may providethe card provider server with information identifying the card holder asa pre-existing customer of the provider. Once the pre-existing cardholder's information is verified, the pre-existing card holder isunilaterally invited to enroll in a special individually tailored systemoffered by the provider, for which the pre-existing card holder ispre-approved.

In one embodiment, pre-approved prospective card holder or thepre-existing card holder (collectively called “accessing party”)accesses an on-line application system maintained on a card providerserver. The accessing party uses a computer interface to provide theserver with information identifying the accessing party as either apre-approved prospective customer or a pre-approved pre-existingcustomer. The card provider server then verifies that the identifyinginformation is valid. Such validation may include comparing theidentifying information to a database containing a plurality ofpre-approved files, where each file corresponds to the accessing party'sidentification information, or a portion thereof. Once it is determinedthat the accessing party is a valid pre-approved party, the accessingparty is invited to enroll in a system provided by the provider. Theinvitation may include a special offer customized to fit the accessingparty's customer profile.

In another embodiment, the card provider may maintain a separatesolicitation database storing the identifying information of theaccessing party and additionally storing special offers for which theperson is pre-approved. Once the accessing party's identification isverified, the accessing party's identifying information is matched to acorresponding special offer stored on the solicitation database. Thecorresponding special offer and identifying information is then providedto the accessing party for verification and acceptance. If verified andaccepted, an enrollment application containing the accessing party'sidentification information is processed in substantially real-time andthe accessing party is provided transaction account (e.g., transactioncard, line of credit account, etc.) information corresponding to animmediately accessible transaction account (e.g., real-time account).The substantially real-time account may then be made immediatelyavailable for use by the accessing party.

In yet another embodiment, the card provider may maintain a separatepre-existing card holder database, storing the customer profile of thepre-existing card holder. In addition, the pre-existing card holderdatabase may also store the special offer for which the pre-existingcard holder is pre-approved. Once the accessing party's identificationis validated, the accessing party may be unilaterally provided with anoffer for special enrollment and a portion of the accessing party'scredit profile. The accessing party may then validate the information,after which, the accessing party is enrolled in the special system ofthe provider, in accordance with the corresponding special offer.

In yet another embodiment, the card provider may maintain a pre-approveddatabase containing all offers corresponding to an individual accessingparty. Once the accessing party accesses the on-line application system,the accessing party's identifying information may then be compared tothe pre-approval data entries stored on the pre-approval database toensure that the accessing party is pre-approved for a special offerprovided by the card provider. Upon verifying that the accessing partyis pre-approved for a special offer, the accessing party is then invitedto enroll in a system provided by the card provider in accordance withthe individual customer profile of the accessing party. If enrolled, theaccessing party is provided with real-time transaction accountinformation permitting the accessing party to immediately use thetransaction account.

Further still, in another embodiment, the card provider may permit theaccessing party to apply for special enrollment where the accessingparty's identifying information may not be matched to the informationstored on either the pre-existing customer database, solicitationdatabase or the pre-approval database. In this case, the accessing partyinformation is processed for providing the accessing party with atransaction account which may be used once the relevant transactionaccount information is forwarded to the accessing party. In thisinstance, the relevant transaction account information may be providedto the accessing party at a later date. Such relevant information may beprovided to the accessing party via mail, or alternatively, may beprovided to the accessing party in an electronic communication providedto the accessing party once the processing of the accessing party'sidentifying information is complete.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject invention will hereinafter be described in the context ofthe appended drawing figures, wherein like numerals denote likeelements, and:

FIG. 1A is an exemplary schematic block diagram of a pre-approval cardprovider system in accordance with an exemplary embodiment of thepresent invention;

FIG. 1B is another exemplary schematic block diagram of a pre-approvalcard provider system in accordance with another exemplary embodiment ofthe present invention; and

FIG. 2 is a flowchart illustrating a system and method for providinginstant transaction account pre-approval in accordance with an exemplaryembodiment of the present invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

The present invention may be described herein in terms of functionalblock components and various processing steps. It should be appreciatedthat such functional blocks may be realized by any number of hardwareand/or software components configured to perform the specifiedfunctions. For example, the present invention may employ variousintegrated circuit (IC) components, e.g., memory elements, processingelements, logic elements, look-up tables, and the like, which may carryout a variety of functions under the control of one or moremicroprocessors or other control devices. Similarly, the softwareelements of the present invention may be implemented with anyprogramming or scripting language such as C, C++, Java, COBOL,assembler, PERL, or the like, with the various algorithms beingimplemented with any combination of data structures, objects, processes,routines or other programming elements. Further, it should be noted thatthe present invention may employ any number of conventional techniquesfor data transmission, signaling, data processing, network control, andthe like. Still further, the present invention may incorporate securityor fraud prevention components, such as, encryption, decryption and thelike. For a basic introduction of suitable encryption or cryptographytechniques, please review a text written by Bruce Schneier which isentitled “Applied Cryptography: Protocols, Algorithms, And Source CodeIn C,” published by John Wiley & Sons (second edition, 1996), which ishereby incorporated by reference.

In addition, it should be appreciated that the particularimplementations shown and described herein are illustrative of theinvention and its best mode and are not intended to otherwise limit thescope of the present invention in any way. Indeed, for the sake ofbrevity, conventional data networking, application development,encryption, cryptographs and other functional aspects of the systems(and components of the individual operating components of the systems)may not be described in detail herein. Furthermore, the connecting linesshown in the various figures contained herein are intended to representexemplary functional relationships and/or physical couplings between thevarious elements. It should be noted that many alternative or additionalfunctional relationships or physical connections may be present in apractical electronic transaction or file transmission system.

To simplify the description of the exemplary embodiments, the inventionis described as pertaining to a system facilitating communicationbetween an accessing party and card provider using a computer networksuch as the Internet. Further, it should be appreciated that the networkdescribed herein may include any system for exchanging data ortransacting business, such as the Internet, an intranet, an extranet,WAN, LAN, satellite communications, and/or the like. That is,communication between the parties to the transaction and the system ofthe present invention is accomplished through any suitable communicationmeans, such as, for example, a telephone network, Intranet, Internet,point of interaction device (point of sale device, personal digitalassistant, cellular phone, kiosk, etc.), online communications, off-linecommunications, wireless communications, and/or the like. The users mayinteract with the system via any input device (e.g. card holderinterface) such as a keyboard, mouse, kiosk, personal digital assistant,handheld computer (e.g., Palm Pilot®), cellular phone and/or the like.Similarly, the invention could be used in conjunction with any type ofpersonal computer, network computer, workstation, minicomputer,mainframe, etc., running any operating system such as any version ofWindows, Windows NT, Windows 2000, Windows 98, Windows 95, MacOS, OS/2,BeOS, Linux, UNIX, or the like. Moreover, although the invention isfrequently described herein as being implemented with TCP/IPcommunications protocols, it will be readily understood that theinvention could also be implemented using IPX, Appletalk, IP-6, NetBIOS,OSI or any number of existing or future protocols. Further, the presentinvention might employ any number of conventional techniques for datatransmission, signaling, data processing, network control, and the like.For example, radio frequency (RF) or other wireless techniques could beused in place of any network technique described herein.

Further still, the terms “Internet,” “computer network” or “network” mayrefer to the Internet, any replacement, competitor or successor to theInternet, or any public or private internetwork, intranet or extranetthat is based upon open or proprietary protocols. Specific informationrelated to the protocols, standards, and application software utilizedin connection with the Internet may not be discussed herein. For furtherinformation regarding such details, see, for example, Dilip Naik,Internet Standards and Protocols (1998); Java 2 Complete, variousauthors, (Sybex 1999); Deborah Ray and Eric Ray, Mastering HTML 4.0(1997). Loshin, TCP/IP Clearly Explained (1997). All of these texts arehereby incorporated by reference.

While the terms “transaction card”, “credit card accounts,” “transactionaccount,” “card holder account” or “credit card” may be used in theexemplary embodiments, the invention contemplates the use of any type offinancial or transaction account, whether or not associated with aphysical card, such as, for example, debit card, charge card, smartcard, bar coded card, magnetic stripe card, stored value card, meritbased card, temporary use account number, brokerage account, 401K plan,stock account, telephone account, utility account, loyalty pointaccount, and/or the like. One such transaction account which is suitablefor use with this invention is the described by Bishop et al., in theU.S. patent application Ser. No. 09/652,899 entitled “Methods andApparatus for Conducting Electronic Transactions” filed Aug. 31, 2000(herein incorporated in its entirety by reference).

An “account number”, as used herein, includes any device, code, or otheridentifier/indicia suitably configured to allow the consumer to interactor communicate with the system, such as, for example,authorization/access code, personal identification number (PIN),Internet code, other identification code, and/or the like which isoptionally located on a rewards card, charge card, credit card, debitcard, prepaid card, telephone card, smart card, magnetic stripe card,bar code card, radio frequency card and/or the like. The account numbermay be distributed and stored in any form of plastic, electronic,magnetic, radio frequency, audio and/or optical device capable oftransmitting or downloading data from itself to a second device. Acustomer account number may be, for example, a sixteen-digit credit cardnumber, although each credit provider has its own numbering system, suchas the fifteen-digit numbering system used by American Express. Eachcompany's credit card numbers comply with that company's standardizedformat such that the company using a sixteen-digit format will generallyuse four spaced sets of numbers, as represented by the number “0000 00000000 0000”. The first five to seven digits are reserved for processingpurposes and identify the issuing bank, card type and etc. In thisexample, the last sixteenth digit is used as a sum check for thesixteen-digit number. The intermediary eight-to-ten digits are used touniquely identify the customer.

As also used herein, the term “card holder”, “end user”, “consumer”,“customer”, “cardmember”, “business” or “merchant” may be usedinterchangeably with each other, and each shall mean any person, entity,machine, hardware, software or business. Although labeled as a “bank,”the bank may represent other types of card issuing institutions, such ascredit card companies, card sponsoring companies, or third party issuersunder contract with financial institutions. It is further noted thatother participants may be involved in some phases of the transaction,such as an intermediary settlement institution, but these participantsare not shown.

Each participant is equipped with a computing system to facilitateonline commerce transactions. The customer has a computing unit in theform of a personal computer, although other types of computing units maybe used including laptops, notebooks, hand held computers, set-topboxes, and the like. The merchant has a computing unit implemented inthe form of a computer-server, although other implementations arepossible. The bank has a computing center shown as a main framecomputer. However, the bank computing center may be implemented in otherforms, such as a mini-computer, a PC server, a network set of computers,and the like.

Further still, it will be appreciated that many applications of thepresent invention could be formulated. For example, the system could beused to gain real-time transaction account approval when the accessingparty requests enrollment in a card provider system using any conventioncredit, debit, merit or other similar account providing the accountholder purchasing or redeeming capabilities.

Furthermore, the prospective card holder, the pre-existing card holderand the card provider, described herein, may represent individualpeople, entities, business, software, hardware or any other creditaccount or financial account provider or transaction account providersuch as, for example, various types of card issuing institutions, suchas banks, credit card companies, card sponsoring companies, or thirdparty issuers under contract with financial institutions. The paymentnetwork (e.g., transaction processing network or system) may includeexisting proprietary networks that presently accommodate transactionsfor credit cards, debit cards, and other types of financial/bankingcards, such as, for example, the American Express®, and VisaNet®network.

In an exemplary embodiment, the present invention facilitatesdifferentiation of the acquisition experience for pre-approvedprospective card holders and pre-approved existing card holders, fromthat of other external prospects accessing the on-line applicationsystem. FIG. 1A illustrates an exemplary system 100A in accordance withan exemplary embodiment of the present invention. System 100A includesan online infrastructure that may be used to recognize pre-approvedprospective card holders and pre-approved pre-existing card holdershaving a pre-approval status and/or program enrollment eligibilitystatus with the card provider.

With reference to FIG. 1A, exemplary card provider system 100A mayinclude a number of customer interface systems 102 which are configuredto communicate with a card provider server 110 (e.g., card providertransaction processing system) via a network 106 to send and/or receiveinformation (e.g., card holder identity, charge account number,expiration date, purchase history, pre-approval code, etc.) related to atransaction request (e.g. log on request, request for access, purchaserequest, request for pre-approval application, etc.).

In an exemplary embodiment, the transaction request may include apre-approval code and/or card holder identifying information or thelike. The card provider server (e.g. transaction account server) 110 maybe configured to receive the transaction request from the customerinterface 102 and seek validation of the information provided. The cardprovider server 110 may validate the information by matching theinformation to data files stored on either the solicitation database 104or pre-existing customer database 108. Once the information is verified,a special enrollment offer may be provided to the customer interface102. In a particular embodiment the special enrollment offer may becustomized to a particular pre-approved prospective card holder or apre-approved pre-existing customer, in accordance with the accessingparty's customer profile. For example, the special offer may includereduced annual percentage rates (APR) or reduced outstanding balanceinterest rates for accessing parties with an exceptional credit orlending history, or alternatively, may include higher APR or outstandingbalance interest rates for accessing parties with a less than exceptioncredit or lending history. The interest rates may be dynamic in that theinterest rate may rise or fall according to changes in an accessingparties customer profile, or, for example, changes in the externalinterest rate governing forces as determined by the card provider.

As used herein, the customer profile may include the accessing partiesname, address, time at current address, current income, credit rating,debt to credit ratio or any similar factors used to calculate a creditrating, as well as, purchase or transaction history and customerdemographic categorizations. Such factors are commonly known amongfinancial and card granting institutions, and as such, will not bediscussed in detail herein. Thus, all other methods and criteria fordetermining an accessing parties credit worthiness (e.g., ability totimely repay credit) as are known are considered to be within the scopeof this invention. More particularly, where formulas for calculatingcredit worthiness are required, such calculations may be performed bycard provider server 110, or any similar device capable of performingarithmetic calculations. It is understood, that while not explicitlydiscussed, such devices are common to card provider systems and aretherefore considered within the scope of the present invention.

Card provider server 110 may be any conventional server (e.g.transaction account server) known in the art, including means forreceiving card holder transaction requests (e.g., enrollment orpurchases request, etc.) via the internet 106, processing suchtransaction requests and sending confirmation or denial of thetransaction requests to customer interface 102. Customer interface 102may be suitably coupled to the card provider 110 via network 106 anddata lines 103 and 105. Card provider server 110 may be suitably coupledto the network 106 via data link 105, and to solicitation database 104and pre-existing database 108 via data links 107 and 109, respectively.

As used herein, database may include any type of database, such asrelational, hierarchical, object-oriented, and/or the like. Commondatabase products that may be used to implement the databases includeDB2 by IBM (White Plains, N.Y.), any of the database products availablefrom Oracle Corporation (Redwood Shores, Calif.), Microsoft Access byMicrosoft Corporation (Redmond, Wash.), or any other database product.Database may be organized in any suitable manner, including as datatables or lookup tables. Association of certain data may be accomplishedthrough any data association technique known and practiced in the art.For example, the association may be accomplished either manually orautomatically. Automatic association techniques may include, forexample, a database search, a database merge, GREP, AGREP, SQL, and/orthe like. The association step may be accomplished by a database mergefunction, for example, using a “key field” in each of the manufacturerand retailer data tables. A “key field” partitions the databaseaccording to the high-level class of objects defined by the key field.For example, a certain class may be designated as a key field in boththe first data table and the second data table, and the two data tablesmay then be merged on the basis of the class data in the key field. Inthis embodiment, the data corresponding to the key field in each of themerged data tables is preferably the same. However, data tables havingsimilar, though not identical, data in the key fields may also be mergedby using AGREP, for example.

A variety of conventional communications media and protocols may be usedfor data links 103, 105, 107, and 109. Such links might include, forexample, a connection to an Internet System Provider (ISP) over thelocal loop as is typically used in connection with standard modemcommunication, cable modem, Dish networks, ISDN, Digital Subscriber Line(DSL), or various wireless communication methods. In addition, customerinterface system 102, card provider system 110, solicitation database104 and pre-existing card holder database 108 might each independentlyand separately, or collectively, reside within a local area network(LAN) which interfaces to network 106 via a leased line (T1, D3, etc.).Such communication methods are well known in the art, and are covered ina variety of standard texts. See, e.g., Gilbert Held, Understanding DataCommunications (1996), hereby incorporated by reference.

Customer interface 102 may include any convenient combination ofhardware and software components configured to allow a customer (orprospective customer) to communicate over network 106. For example,customer interface 102 might include a standard personal computer (PC)comprising a CPU, monitor, storage, keyboard, mouse, and communicationhardware appropriate for the given data link 103 (e.g., V.90 modem,network card, cable modem, etc.). In alternate embodiments, customerinterface system 102 may be a personal data assistant (PDA) capable ofmanipulating images and communicating with merchant server 110. Customerinterface system 102 typically may typically include an operating system(e.g., Windows 95/98/2000, Linux, Solaris, MacOS, and/or the like) aswell as various conventional support software modules and driverstypically associated with computers. Customer interface system 102 mayalso include application software configured to communicate over network106 with card provider server 110, for example, a world wide web (WWW)browser or any other communication software. In an exemplary embodiment,customer interface system 102 includes a conventional Internet browserapplication that operates in accordance with HTML and HTTP protocolssuch as Netscape Navigator (available from the Netscape Corporation ofMountain View, Calif.) or Microsoft Internet Explorer (available fromthe Microsoft Corporation of Redmond, Wash.).

Card provider server 110 may comprise any number of hardware, software,and networking components suitable to provide an user interface to anetwork 106, solicitation database 104 or pre-existing customer database108, as described in further detail below. In one embodiment, cardprovider server 110 may include Sun Ultra SPARC Enterprise 250 and 450servers which may be used in conjunction with a Sun Solaris 7 or Linuxoperating system, Apache web server software, and an Oracle 8 or MySQLdatabase system. Of course, particular hardware and software componentsused in card provider server 110 will vary widely from embodiment toembodiment. Furthermore, card provider server 110 may represent a“cluster” or group of separate computer systems providing thefunctionalities described herein.

In a typical card provider environment, solicitation database 104 andpre-existing customer database 108 may include a plurality of distinctlocations for maintaining individual pre-existing card holder orpre-approved prospective card holder information, such as card holderidentity, account number, account balance, amount available, purchasehistory, etc. For example, in one embodiment, a distinct location mayinclude the customer profile of a single pre-approved prospective cardholder or a pre-existing card holder. In another embodiment, thedistinct locations may additionally include customized pre-approvaloffers corresponding the individual prospective card holder orpre-existing card holder's identity. That is, the distinct locations maystore not only the customer profile for a particular party, but also thedistinct pre-approval offer corresponding to that party's customerprofile. The database 104 and 108 may be a graphical, hierarchical,relational, object-oriented or other database, and may be maintained ona local drive of server 110 or on a separate computer coupled to server110 via a local area or other network (not shown). In one embodiment,the database may be a collection of ASCII or other text files stored ona local drive of server 110. Pre-approved prospective card holder andpre-existing card holder account information may be suitably retrievedfrom the database and provided to customer interface 102, upon requestvia a server application, as described more fully below.

As noted, within each pre-existing customer database there may be storeda plurality of individual data locations corresponding to the customerprofile and/or enrollment offer for each pre-approved pre-existingcustomer. In one embodiment, pre-existing customer database 108 ismanaged by the server 110 which is maintained by a credit card providerwith which the pre-existing card holder has established a billingaccount. The billing account may be associated with any suitable creditcard system such as Visa®, MasterCard®, American Express®, Discover®, orthe like. Further, the billing account may additionally allow the cardprovider to recover payment for charges made by an individual customerwho is a subscriber of the credit card system.

Similarly, solicitation database 104 may also be managed by the server110. The distinct individual data locations stored on the solicitationdatabase 104 may include any information relevant to the identity and/orcustomer profile of any pre-approved prospective card holders. In someinstances, a card provider may only have rudimentary information (e.g.,name address, occupation, etc.) concerning the pre-approved prospectivecard holder. In that case, upon a suitable request to the solicitationdatabase 104 by the card provider server 110, an incomplete creditprofile may be provided to the customer interface 102 via network 106.At customer interface 102, the accessing party may be asked to providemissing credit profile information.

It should be noted that the information stored in the individual datalocations may be provided to the customer interface 102 in any formatwhich allows the accessing party to input the information into thecustomer interface 102 for receipt and real-time processing by the cardprovider server 110. In a typical example, the customer profile may beprovided as a part of the provider's on-line application system process.For example, the information may be provided as a part of an on-lineapplication system by populating on the customer interface 102 apre-filled or partially pre-filled browser compatible web page (e.g.,pre-filled or partially pre-filled application). In this way, the webpage application provided to the customer interface 102 may be madepersonal to the accessing party. That is, the web page application maycontain only the accessing party's individual information (e.g.,customer profile) and any information pertaining to enrollment offerscustomized for that accessing party.

As used herein a pre-filled web page application contains various entryfields or data fields wherein each entry field corresponds to a portionof the data contained in the pre-approved prospective card holder orpre-approved pre-existing card holder customer profile. For example,where the web page displays the accessing party's name, address, yearlyincome, or the like, each of the name, address, and yearly income mayoccupy only one entry field. Further, each entry field may be configuredsuch that the accessing party may update the accessing party'sidentifying information using the customer interface 102. That is, priorto submitting the information to the card provider server 110 forprocessing, where one or more of the entry fields contains incorrectdata, the accessing party may be permitted to update that entry fieldaccordingly. In this way, the accessing party may be permitted tovalidate that the accessing party's customer profile stored on thesolicitation database 104 or the pre-existing card holder database 108is correct.

Similarly, where the information displayed on the customized web page isincomplete, the web page may be only partially pre-filled and theaccessing party may be permitted to provide the missing informationprior to submitting the information to the card provider server 110 forprocessing. That is, the information contained on the databases 104 and108 may be missing one or more important pieces of data required forcalculating an accessing party's special offer interest rate, repaymentinterest rate, APR or the like. For example, the information may notinclude the accessing party's annual income, or additional debtliability or assets not known to the card provider. In this instance,the accessing party may be permitted to provide the information insimilar manner as was described above with respect to the accessingparty's ability to change errant information. Such providing of missinginformation may take place prior to the accessing party providing theon-line application to the card provider server 110 for processing.

By providing the accessing party with pre-filled and partiallypre-filled personalized web pages, the card provider is capable ofreducing the number of application fields the accessing party needs tocomplete, as compared to conventional on-line application methods. This,in turn, reduces the amount of application processing time andexpenditure associated with traditional direct mail and telephonicmethods. In addition, the pre-filled or partially pre-filled pagesprovide a more convenient method for the applications to be submittedand processed.

FIG. 1B depicts another exemplary embodiment of a card provider system100B in accordance with the present invention, wherein like elements asto FIG. 1A have like descriptions. Included in FIG. 1B, however, may beseparate pre-approved customer database 112 and a financial accountapproval server 114, which are connected to card provider server 110 viadata links 111 and 113, respectively. Data links 111 and 113 are of asimilar description to similar elements of FIG. 1A. Further, financialaccount approval server 114 may be of similar description as that ofcard provider server 110. Further still, the architecture ofpre-approved customer database 112 is of similar description as that ofpre-existing customer database 108 and solicitation database 104, inthat the pre-approved customer database may include distinct datalocations for storing information pertaining to each distinctpre-approved prospective card holder and/or each pre-approvedpre-existing card holder. That is, in this embodiment the information(e.g., credit profile) correlating to each pre-approved accessing partymay be stored in the pre-approved customer database 112 in distinct datafiles. In this case, where the accessing party initiates thepre-approval process by providing to the card provider server 110identifying information the card provider server 110 may seek tovalidate the provided identifying information by matching theidentifying information to a distinct file stored on the pre-approvedcustomer database 112.

As noted, financial account approval server 114 may be of similardescription and operation as that of card provider server 110. In thisparticular embodiment, however, financial server 114 may be used toprocess the accessing party's customer profile information after theinformation is verified by the accessing party at customer interface102. That is, the information may be verified by the accessing party atcustomer interface 102, after which the information may be forwarded tothe financial account approval server 114 directly or via the cardprovider server 110. In such case, the financial account approval server114, may process the information in similar manner as was describedabove with respect to the card provider server 110.

It should be understood that in some instances, a card provider maydesire to provide the customer interface 102 with other messages or webpages apart from the individual web page corresponding to a particularaccessing party. Such other web pages may be promotional web pages,status web pages or the like. Consequently, one skilled in the art willunderstand that such web pages may be provided to the customer interface102 by card provider server 110 from the card provider server 110location, or any such suitable device for providing canned (e.g.,pre-prepared) web pages to a customer interface 102. Although notillustrated with respect to FIGS. 1A and 1B, such devices are commonlyknown, and as such, will not be discussed herein in their entireties.

The operation of the present invention may be more fully understood withreference to FIG. 2 and continued reference to FIGS. 1A and 1B. FIG. 2depicts a flow chart of an exemplary card provider system 200 inaccordance with the present invention. As shown, the operation of system200 begins with step 202 where an accessing party provides anidentifying code (e.g., access code) to card provider server 110 vianetwork 106 and customer interface 102. The access code, or accessingsignal, may include information which may be used to facilitateidentification of the accessing party. For example, where the accessingparty is a pre-existing card holder, the accessing code may be the cardholders name, credit card number or any such code provided to theaccessing party by the card provider for the purpose of identifying theaccessing party or accessing party transaction account. Where theaccessing party is a prospective customer, the access code may be apassword or code individualized to that particular accessing party. Thatis, in a typical example, the code may consist of a combination of ASCIIcharacters, the persons first or last name, or a combination thereof. Inany event, the access code may be one which is used by the card providerto facilitate determining the accessing party's identity or dataassociated with the accessing party.

Upon receiving the access code, the server 110 may then verify whetherthe access code belongs to an accessing party who is an established(e.g. pre-existing) card holder of the card provider systems (step 204).For example, the server 110 may seek to facilitate matching theaccessing code to a distinct data profile stored on pre-existingcustomer database 108 (step 204). In a typical matching method, theaccess code is compared to the distinct data files stored inpre-existing customer database to determine if the accessing party'sidentification information may be found in the database 108. Where theaccessing code does not correspond to a distinct profile in database108, the accessing party may not be provided access to a secured area ofthe card provider system 100 to continue the accessing party's intendedtransaction.

Where the card provider server 110 is able to help locate a matchingprofile, the server 110 may then seek to determine if the pre-existingcard holder is eligible for receipt of any pre-approved offers (step206). In one embodiment, the pre-approved offer may be stored on thepre-existing customer database 108 correlative to the distinct dataprofile corresponding to the access code provided by the accessingparty, as is described with respect to FIG. 1A. In which case, theserver 110 may provide the accessing party notification of the accessingparty's pre-approval status (step 210). Once the accessing party isinformed of his pre-approval status, the accessing party is given anopportunity to apply for the enrollment in the special offer including acustomized special offer corresponding to the accessing party'spre-approval status (step 212). The invitation may be provided to theaccessing party at the customer interface 102 in the form of acustomized on-line application system web page or promotional pagepopulated on the interface 102. If the accessing party does not elect toapply for the customized special offer (step 212), the server 110 maythen provide the accessing party access to a secured area of the cardprovider system 100A, 100B, where the secured area is reserved for cardholders only. Contractually, the accessing party, who refuses to offer,may be returned to the entry page of the card provider web site (step208).

If the accessing party elects to apply for the customized special offer(step 212) the customer profile information corresponding to (e.g.matching) the accessing party's access code is provided to the accessingparty by facilitating the population of a pre-filled application oncustomer interface 102. In one embodiment, where the correspondingprofile is located by the server (step 214), it may be accompanied by atleast one special offer (e.g., customized offer) for which the accessingparty qualifies. In this case, the special offer is provided to theaccessing party along with a personalized web page containing theaccessing party's customer profile (or a portion thereof) in a formatallowing the accessing party to verify or change the profile (step 216).

In some cases, in step 214 it may be require that the accessing partyaccess code be first checked against the distinct files stored on apre-approval database 112, containing a plurality of distinctpre-approval codes corresponding to distinct access codes. In this case,the server 110 may facilitate comparison of the access code to the filesstored on the pre-approval database to ensure that the accessing partyis eligible for receipt of a pre-approval offer (step 214). Thisverification process may involve the server 110 finding a matchingaccess code on the pre-approval database 112. Where a match is found, itmay be determined that the accessing party is eligible for receipt of acustomized offer. That is, the server 110 has matched the access code toa corresponding pre-existing customer (e.g. card holder) profile on thepre-existing customer database 108. In this case, the customer profileit may be accompanied by at least one special offer (e.g., customizedoffer) for which the accessing party qualifies. The special offer isthen provided to the accessing party along with a personalized web pagecontaining the accessing party's customer profile (or a portionthereof). Here, the special offer may be provided in a format allowingthe accessing party to verify or change the information stored in thecustomer profile (step 216).

As noted above, the information stored on the pre-existing customerdatabase may be incorrect, outdated or incomplete. Consequently, whenthe accessing party is provided the profile, the accessing party may begiven the opportunity to correct the errant information or verify thatthe information contained on the customized web page is correct. If theidentifying information is incorrect, outdated or incomplete, theaccessing party may then be permitted to update the information andprovide the information to the card provider server 110. Once theaccessing party makes changes to the information displayed on the webpage, the information is deemed unverified or uncorroborated (step 218),and the accessing party's information, including the updatedinformation, may be processed as an un-pre-approved application (step220). That is, the accessing party is deemed to not be eligible forpre-approval status permitting receipt of real-time account informationand the application is processed under normal processing procedures(e.g. businesses usual standard) as established by the card provider(step 220). Where the application is processed under normal processingprocedures, the accessing party is notified that the accessing party isconditionally approved, delayed approved, not approved or the like (step222) and the accessing party may then be provided access to a securedarea of the card provider's web site to complete his intendedtransaction (step 208). Alternatively, where the accessing party'sinformation is deemed un-pre-approved, the accessing party's informationmay be processed such that a transaction account may be established forthe accessing party, but the transaction account information may not beprovided to the accessing party in real-time. Instead, the transactionaccount information may be provided to the accessing party at a laterdate via conventional notification methods (e.g. electronic mailtransactions, a postal mailing, etc.). In this way, a decision regardingthe accessing party's approval status may be made substantiallyinstantaneously.

If the accessing party facilitates verification that the accessingparty's corresponding information as it is stored on the pre-existingcustomer database is correct, then the accessing party's application forenrollment in the customized program is processed as a pre-approvedapplication for real-time approval (step 224). Such processing may beperformed by the card provider server 110, or by a financial accountapproval server 114 remote from the card provider server. The processingsteps for processing the pre-approved application may take any form asdetermined by the card provider. At the completion of the processingsteps, a new transaction account corresponding to the special enrollmentoffer may be activated (step 226) and a message including the accessibleaccount information (e.g., transaction account number, credit line,annual percentage rate, interest on outstanding balance, etc.) may beforwarded to the accessing party via the card provider server 110 (step228). In an exemplary embodiment, the account information is accessiblein substantially real-time. In this way, the accessing party is providedan accessible transaction account in substantially real-time, which maybe used, immediately in an exemplary embodiment, for performingfinancial transactions. The accessing party may then be provided accessto a secured area of the card provider system 100A, 100B, for conductinghis intended transaction or to the web site entry page (step 208).

In the instance where the server 110 facilitates determination that theaccess code provided by the accessing party does not sufficientlycorrespond to an account of a pre-existing card holder (step 204), theaccess code may be validated (step 230). In this case, the access codemay include information identifying the accessing party as a prospectivepre-approved customer. As noted, such an access code may be parsed intoparts identifying the customer's identity, and the accessing partiespre-approval status. For instance, an exemplary access code may includea pre-approval code and up to the first seven letters of the accessingparties last name. The server 110 may then take the received access codeand validate the code by comparing the code to the distinct pre-approvalcodes stored in distinct locations on a pre-approved customer profiledatabase 112. If the access code is not matched to a data location onthe profile database 112, the access code is deemed invalid (step 232)and a message informing the accessing party of the invalid status isforwarded to the accessing party (step 234). The accessing party maythen be permitted to re-enter the access code or provide a differentaccess code for verification (step 234). If the accessing party providesan alternate access code, the access code may then enter the validationstep for determining the validity of the code (step 230). Alternatively,if the accessing party does not enter an alternate access code orreenters the first provided access code, the instant pre-approvalprocess described in FIG. 2, may be terminated. Such termination ofprocess may take place after the card provider server receives oneinvalid access code entry or a pre-determined number of access codeentries, as determined by the card provider.

If the access code is matched to a data location on the pre-approvedcustomer database 112, the access code is deemed valid (step 230). Inwhich case, the access code may be matched against the distinct datafiles stored in the solicitation database 104 (step 236). In oneembodiment, the data files may include only the customer profileinformation. In another embodiment, the data profile may include thecustomer profile and any pre-approval offers for which the accessingparty qualifies. The data profile corresponding to the access code maythen be retrieved (step 236) and provided to the accessing party in amanner permitting the accessing party to verify the informationcontained in the data profile (step 238). That is, the profile may beprovided in the form of a pre-filled, or partially pre-filled customizedweb page as described above. The provided web page may permit theaccessing party to verify the corresponding information stored in thesolicitation database 104, or to update the information as necessary(step 240). Where the accessing party elects to submit the web page(e.g. on-line application) unchanged, the information is deemed verified(step 240) and the application is process as a pre-approved application(step 224) in similar manner as with respect to the pre-existing cardholders described above. That is, a real-time transaction account may beestablished for the accessing party (step 226) and information regardingthe real-time transaction account provided to the accessing party viathe card provider server 110 and the customer interface 102 (step 228).The accessing party may then be provided substantially real-time accessto a secured location of the card provider system 100A, 100B.Alternatively, the accessing party may be returned to the web site entrypage (step 208).

It should be understood that the present invention is suitable for anysystem utilizing an on-line application process. For example, the systemmay be used with on-line systems employing any credit, banking orloyalty program, and any program concerning on line activation. Suchexemplary systems are disclosed in U.S. Provisional Ser. No. 60/197,296filed Apr. 14, 2000, U.S. Provisional 602/200,492, filed Apr. 28, 2000,U.S. Provisional No. 60/201,114 filed May 2, 2000, and U.S. ProvisionalNo. 60/272,487 filed Feb. 27, 2001, all of which are hereby incorporatedby reference.

It should be further understood that exemplary embodiments and systemfunctions of the present invention include facilitating consultativecard selling capabilities on-line, including: recognizing existing cardproducts held by the accessing party, providing card pre-approval statusvia on-line communication, providing enrollment in rewards programs,matching access codes against a pre-approved eligibility file, removingor populating as many entry fields on an application as is desired, andaccessing real-time pre-existing card holder or prospective card holderinformation from multiple mainframe systems.

In addition, the present system may be designed to support two types ofactivity, namely when a pre-existing card holder accesses a cardprovider on-line application system unsolicited, and when a pre-approvedprospective card holder accesses the on-line application system due tonotification of the accessing party's pre-approval status. In theinstance where the accessing party is a pre-existing card holder, thecard holder may log onto the on-line application system via a SingleSign On (SSO) application after having first registered at least one ofthe accessing party's existing card products with the card provider. Inthis case, the system may readily match the accessing party to thecorrelative identifying information, which allows the system toinstantly recognize the accessing party as a pre-existing card holder,and to recognize the systems for which the accessing party is alreadyenrolled.

If the accessing party is eligible for more than one special (e.g.customized) offer, then the system may incorporate on the card providerserver 110, business logic which determines which special offer, oroffers, to provide to the accessing party. If the accessing party electsto apply for a special offer, the customer profile information displayedto the accessing party may not include certain sensitive information(e.g., social security number, address, etc.) due to fraud concerns. Thesensitive information, however, may be blindly passed by the system to aprocess server for processing the pre-approval application.

In the foregoing specification, the invention has been described withreference to specific embodiments. However, it will be appreciated thatvarious modifications and changes can be made without departing from thescope of the present invention as set forth in the claims below. Forexample, various processing steps may be combined or eliminated asrequired. Further, various system elements described herein may beeliminated, and various steps may be performed by one or more of theelements described herein. In addition, other suitable elements may besubstituted for the elements described herein, or inserted between theconnecting lines of the embodiments set forth, without departing fromthe scope of this invention. Further still, the specification andfigures are to be regarded in an illustrative manner, rather than arestrictive one, and all such modifications are intended to be includedwithin the scope of present invention. Accordingly, the scope of theinvention should be determined by the appended claims and their legalequivalents, rather than by the examples given above. For example, thesteps recited in any of the method or process claims may be executed inany order and are not limited to the order presented in the claims.

In addition, the benefits, other advantages, and solutions to problemsdescribed have been illustrated above with regard to specificembodiments. However, the benefits, advantages, solutions to problems,and any element(s) that may cause any benefit, advantage, or solution tooccur or become more pronounced are not to be construed as critical,required, or essential features or elements of any or all the claims. Asused herein, the terms “comprises,” “comprising,” or any other variationthereof, are intended to cover a non-exclusive inclusion, such that aprocess, method, article, or apparatus that comprises a list of elementsdoes not include only those elements but may include other elements notexpressly listed or inherent to such process, method, article, orapparatus. Further, no element described herein is required for thepractice of the invention unless expressly described as “essential” or“critical”.

1. A method, comprising: receiving, by a computer based system forproviding an offer, an access code from a customer, wherein the customeris at least one of a prospective customer and an existing customer, andwherein the access code was provided to the customer, and wherein theaccess code cannot be used to transfer funds via an account issuer; andproviding, by the computer based system, the offer from a plurality ofstored offers to the customer based at least in part on the access codeand whether the customer is the at least one of the prospective customerand the existing customer.
 2. The method of claim 1, further comprisingdetermining, by the computer based system, whether the customer is aprospective customer or an existing customer based at least in part onthe respective access code.
 3. The method of claim 1, wherein the accesscode is received at an interface of the account issuer.
 4. The method ofclaim 1, further comprising performing, by the computer based system, atleast one of a removal of fields and a population of fields at aninterface of the account issuer based at least in part on a profileassociated with the access code.
 5. The method of claim 1, wherein anamount of personal information requested from the existing customer isless than an amount of personal information requested from theprospective customer.
 6. The method of claim 1, wherein the providingfurther comprises matching the access code to a profile in a databasefor the existing customer.
 7. The method of claim 1, wherein the offeris based upon a profile associated with the customer.
 8. The method ofclaim 1, further comprising providing the offer in an application for atransaction account.
 9. The method of claim 1, further comprisingmatching the access code to a pre-approval code.
 10. The method of claim1, further comprising validating the profile.
 11. The method of claim 1,further comprising approving an application for a transaction account,wherein the approving is performed in real-time and wherein thetransaction account is associated with transaction account information.12. The method of claim 1, wherein at least a portion of the profile isprovided in a form of a plurality of modifiable entry fields.
 13. Asystem comprising: a tangible, non-transitory memory communicating witha processor for providing an offer, the tangible, non-transitory memoryhaving instructions stored thereon that, in response to execution by theprocessor, cause the processor to perform operations comprising:receiving, by the processor, an access code from a customer, wherein thecustomer is at least one of a prospective customer and an existingcustomer, and wherein the access code was provided to the customer, andwherein the access code cannot be used to transfer funds via an accountissuer; and providing, by the processor, the offer from a plurality ofstored offers to the customer based at least in part on the access codeand whether the customer is the at least one of the prospective customerand the existing customer.
 14. The system of claim 13, furthercomprising determining, by the computer based system, whether thecustomer is a prospective customer or an existing customer based atleast in part on the respective access code.
 15. The system of claim 13,wherein the access code is received at an interface of the accountissuer.
 16. The system of claim 13, further comprising performing, bythe computer based system, at least one of a removal of fields and apopulation of fields at an interface of the account issuer based atleast in part on a profile associated with the access code.
 17. Thesystem of claim 13, wherein an amount of personal information requestedfrom the existing customer is less than an amount of personalinformation requested from the prospective customer.
 18. The system ofclaim 13, wherein the providing further comprises matching the accesscode to a profile in a database for the existing customer.
 19. Thesystem of claim 13, wherein the offer is based upon a profile associatedwith the customer.
 20. An article of manufacture including anon-transitory, tangible computer readable medium having instructionsstored thereon that, in response to execution by a computing device forproviding an offer, cause the computing device to perform operationscomprising: receiving, by the computer based system, an access code froma customer, wherein the customer is at least one of a prospectivecustomer and an existing customer, and wherein the access code wasprovided to the customer, and wherein the access code cannot be used totransfer funds via an account issuer; and providing, by the computerbased system, the offer from a plurality of stored offers to thecustomer based at least in part on the access code and whether thecustomer is the at least one of the prospective customer and theexisting customer.